The present invention relates to peripheral devices for computers and in particular to USB peripheral devices that include programmable controllers.
Personal computers cooperate with a large variety of peripheral devices (peripherals), such as magnetic, optical and solid-state disks; printers; modems; keyboards; mice; etc. Many of the peripheral devices are removably-connected to the personal computer via a Universal Serial Bus (USB) connection. The communication between an application running on a personal computer and a peripheral that is needed for that application is controlled by the computer's operating system (OS), under standard protocols (the OS' services).
Under common conventions, some OS services are considered risky to an IT (information technology) system of an organization, and therefore are defined as restricted services accessible only to users that are classified as administrators. Non-administrator users are provided with access only to standard services, which represent no risk or low-risk to the IT system.
FIGS. 1-3 schematically illustrate the prior art with respect to computers, OS services and peripherals. FIG. 1 is a schematic high-level block diagram of a computer system 100 that includes a host computer 110, such as a personal computer (desktop, laptop or palmtop), or a cellular telephone enhanced with computing capabilities. System 100 also includes a client peripheral device 120 connected permanently or temporarily to computer 110 through a link 105. Computer 110 includes a CPU 112 that runs user applications 118. A Universal Serial Bus (USB) interface 116 in computer 110 provides electrical, logical and mechanical connections with a corresponding USB interface 126 in peripheral 120, to establish link 105. An operating system 114 governs the operation of CPU 112, and the way CPU 112 interfaces with applications 118 on the one hand and peripheral 120 on the other hand. Peripheral 120, in the context of the present invention, is smart in the sense that peripheral 120 includes a controller 122 operating under controller firmware 124. Functions 128 generally represent the hardware and software components for which peripheral 120 has been connected to computer 110. Exemplary functions 128 include printing, storage, data entry (e.g. keyboard, mouse), data display, a webcam etc. In some embodiments, functions 128 utilize controller 122 for processing, and in other embodiments functions 128 employ another controller: In any case, in the context of the present invention, controller 122, under programs from firmware 124, monitors and controls the data traffic between computer 110 and functions 128. For example, controller 122 receives, via link 105, USB packets that are issued by the services of operating system 114 and interprets those packets for functions 128. Link 105 is implemented via direct contact, cable or wireless communication.
FIG. 2 is a simplified structural diagram of operating system 114, which is actually a software package. Operating system 114 includes services 114S and permissions 114P. Services 114S are software routines that govern the general functionalities of computer 110 and the communication of computer 110 with peripheral 120. Thus, a user application 118 that needs access to a peripheral 120, such as a disk, a printer or a keyboard, calls the respective service from services 114S to interface with the required peripheral 120. Permissions 114P is a database of users or user types that specify whether a current computer user, identified through a previous login session or by entering a password, is permitted to access a certain service from among services 114S. For brevity and clarity the discussion hereinbelow will focus on two user types: administrators who have permission to access all services 114S, and non-administrators who have access to only standard services 114S, while being barred from accessing restricted services 114S that are more risky to the associated IT system. In this context, the IT system may be computer 110 and its contents as a minimum, or a corporate network that includes computer 110 in another typical case. It will be appreciated that more sophisticated permission hierarchies are common in the art, for allowing operating system 114 to determine whether a certain service from among services 114S is allowed to or barred from a certain user under permissions 114P.
FIG. 3 is a flowchart of the operation of computer system 100 under operating system 114. In step 200 application 118 orders a certain service of services 114S from CPU 112 running under operating system 114. In step 202, operating system 114 checks whether the requested service is standard, i.e. allowed for all users. If the answer is positive, then the requested service is executed in step 206. Otherwise, i.e. if the service is determined to be restricted in step 202, operating system 114 checks in permissions 114P whether the current user, as previously identified through a log-in procedure (or possibly by having successfully entered a password when prompted to do so), has administrator privileges, i.e. is eligible for the requested service. If the answer is positive, then the requested service is executed in step 206. Otherwise, service is denied in step 208, preferably while notifying the user by a message on the screen (not shown) of computer 110. The procedure ends in step 210, when operating system 114 is ready to receive and examine the next service order from an application 118.
New peripheral devices, features and applications are continually developed, and may require new operating system services to access them. Because computer operating systems are standardized across a large number of computers, it may take a very long time to accommodate such new services within OS 114. Therefore, developers of new peripherals, features and applications make any reasonable effort to apply an existing OS service instead of waiting for a new, dedicated service to be developed and integrated into OS 114. A problem arises, however, when a new, harmless peripheral or feature requires an OS service that is restricted because alternative uses of the same service are considered risky.
An example is a mass-storage device that interfaces with personal computers through the USB protocol, implemented under the Microsoft Windows™ OS. As long as the device is used for file read-write operations from and to its storage, existing standard OS services support seamless operation for all users. However, newer mass-storage devices, which include programmable built-in processors, offer more than just storage. For example, these mass storage devices can autonomously password-protect their content, or can double as authentication tokens. Such additional features often require specific data exchange with the built-in processor (e.g. password entry) or from an associated PC application (e.g. during authentication handshaking), but such data exchange requires restricted services that are barred by the Windows™ OS for non-administrator users.
There is thus a widely recognized need to provide a solution for non-administrator users to communicate with a peripheral device for implementing non-standard features that are normally barred by OS restrictions.